Player specific network

ABSTRACT

Embodiments of the invention allow a player to have a unique gaming experience, different than other players, even when playing on the same network. A game may span several gaming sessions. States of a game, for example a bonus game, may be stored when the player decides to stop playing the game. When the player initiates a next gaming session, at the same or another location, the previous state of the game is re-loaded onto the gaming machine and the player returns to the previous state. Further, additional bonuses can be implemented because the network knows the identity and other information about the player. The additional bonuses may be unique to that player. Messages particular to a player are exchanged between a gaming device and a gaming network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. provisional application60/503,516 filed Sep. 15, 2003, entitled Player Specific Network, thecontents of which are incorporated by reference herein. Additionally,this application is related to U.S. non-provisional application Ser. No.10/699,260, entitled Player Specific Rewards, and is related to U.S.patent application Ser. No. 10/247,786, filed on Sep. 18, 2002, entitledPlayer Specific Gaming System, the contents of both of which areincorporated herein by reference.

TECHNICAL FIELD

This disclosure is related to gaming networks and, more particularly, togaming networks that can be tailored based on an identity and/or ahistory of the player.

BACKGROUND OF THE INVENTION

Because there are many choices of casinos from which a patron canchoose, casinos are constantly searching for ways to differentiatethemselves. One such method is by developing new games and gamingenvironments that encourage players to return. Loyalty programs are wellknown; where players earn an award for playing gaming devices with theamount of the award determined by the amount of coins deposited into thegame, game outcome, certain bonuses or extra awards won, or othervarious factors. Typically, the awards accumulate in an account, similarto frequent flyer miles, until used by the patron. By returning to thesame casino, or same group of casinos, the award account can accumulateto a valuable amount.

Although loyalty programs are successful in encouraging patrons toreturn, patrons are always seeking new, unique, and interesting ways tobe entertained and to get a maximum benefit from their entertainmentdollar.

Embodiments of the invention address this need.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of components in an example gamingnetwork according to embodiments of the invention.

FIG. 2 is a functional block diagram of components in an example gamingnetwork according to other embodiments of the invention.

FIG. 3 is a block diagram of a sample game screen according toembodiments of the invention.

FIG. 4 is a block diagram indicating how information can be flowedacross the network of FIG. 1.

FIG. 5 is an example flow diagram of a verification procedure.

FIG. 6 is a block diagram of a personalization network according toembodiments of the invention operating on a single casino.

FIG. 7 is a block diagram of a personalization network according toembodiments of the invention operating on multiple single casinos.

FIG. 8 is a block diagram of a personalization network according toother embodiments of the invention operating on multiple single casinos.

FIG. 9 is a process flow diagram illustrating how the personalizationnetwork according to embodiments of the invention can acquire data.

FIG. 10 is a block diagram illustrating how information can be flowedacross the network of FIG. 1.

FIG. 11 is an example of a personalized calendar according toembodiments of the invention.

FIG. 12 is an example flow diagram illustrating a heartbeat process.

FIG. 13 is a block diagram illustrating how heartbeat messages can bepropagated across a personalization network according to embodiments ofthe invention.

FIG. 14 is a screen shot of an anticipation indicator.

FIG. 15 is a screen shot of an animated anticipation indicator.

FIG. 16 is a screen shot of an animated bonus indicator.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the invention are directed to an electronic gaming devicemachine platform that is operative over a gaming network. A playertracking system can be integrated with the machine via the PSGSArchitecture. Embodiments of the invention allow an ability to trackindividual game activity and adjust game characteristics to meet aplayer's tastes, play habits, and gaming budget, an ability to provideloyalty inducing awards that directly impact game play, and ability toallow a casino to more directly communicate loyalty building promotionalinformation to a customer, and an ability for the casino to rapidlychange loyalty promotions, for instance.

In this disclosure, is assumed that traditional gaming machinefunctionality exists in the game platform as is known in the art, suchas reels, video displays, spin buttons, bet buttons, player trackingsystems, etc.

An architecture system 10 is illustrated in FIG. 1. Generally, thearchitecture system 10 includes player tracking hardware 20, a playertracking system 40, a data interface 60, and a gaming machine 80.Although only one gaming machine 80 is illustrated, multiple gamingmachines 80 would typically be connected in the architecture system 10.

The machine 80 will integrate with the player tracking system 60 via aPlayer Specific Gaming System (PSGS) 70 described below. The PSGS system70 can be a collection of one or more computer servers operating inconjunction to host programs and data to create a user-specific gamingsystem. The PSGS 70 includes of a patron database 72 that stores playerrelated information from play session to play session. It also containsa slot machine database 74. The patron database 72 is linked to eachgaming device 80 by a dedicated high-speed communication network. Thisnetwork is independent from any existing slot accounting/player-trackingnetwork. The PSGS 70 is designed to work in parallel with existing slotaccounting/player-tracking systems.

FIG. 2 illustrates an architecture system 110 similar to thearchitecture 10 of FIG. 1. Additional specific databases 172-179 areillustrated in FIG. 2, but the same data could be stored in otherportions of the architecture 10. Although reference is made in thisdisclosure to the architecture 10 of FIG. 1, embodiments are equallyoperable on like or similar components of other architectures, such asthe architecture 110 of FIG. 2. Discussion of the additionalarchitectures is omitted for brevity.

Reward Mechanisms

Several unique reward mechanisms can be operated on the architecturesystem 10. The game theme will define the basic rules of play for thatgame. Different game themes and art treatments can be applied to eachreward mechanism. The reward mechanisms may have two events, a minorreward, which does not award cash or monetary value, and major rewardthat awards cash or a monetary equivalent. A game theme may have theability to operate more than one reward feature.

An underlying game theme on the gaming machine 80 is a 5 or 9-line, 5reel video slot machine. It is assumed that the game machine 80 includesa second screen reward feature that could be won by carded andnon-carded players alike. The second reward screen feature may be fundedby the overall payback percentage of the machine, however most playerspecific reward features would typically be funded by a reward poolmechanism, as described below. The reward pool mechanism may be fundedsimilar to a progressive.

An example reward pool mechanism defines a minimum and maximum value,and an associated increment rate. The increment rate may be a percent ofcoin-in. The gaming machine 80 chooses a value between the minimum andmaximum value. Each value between the minimum and maximum are likely tobe chosen. This value is given and stored in the PSGS 70. As activity onthe gaming machine 80 occurs, the machine 80 increments the player'sactual value towards the target value. The actual value is managed bythe machine 80 and stored in the PSGS 70. Upon reaching the targetvalue, the machine 80 activates a minor or major reward, as describedbelow.

The target value and actual value are given to PSGS 70 based upon fourcard-in, minor reward, and major reward events, for example. The targetvalue and actual value are given to the machine 80 upon playeridentification card insertion.

The minimum, maximum, and increment rates are configured at the PSGS 70.The random number generator used to choose the value between the minimumand maximum may be located on the machine 80.

Both minor and major rewards can be triggered based upon the reward poolmechanism. The minor reward may always be triggered and the reward poolmechanism does not always trigger the major reward. The machine 80 isresponsible for triggering minors and majors, utilizing informationstored and downloaded from the PSGS 70 or through events that occur innormal game play, example a scatter pay reward game initiator, as isknown in the art.

The player will win a minor reward when the pool mechanism is triggered.The minor reward will be awarded via reward game screens in similarmanner to traditional game reward. The minor reward awards the playerthe opportunity to win cash prizes at a future date, based upon a futureoutcome. The minor reward does not have an actual money value associatedwith the reward until the major reward is triggered at a future date oroutcome.

The major reward can occur in three ways; first, a reward pool mechanismis triggered, second, the player reaches an overall goal, or third,based on a machine outcome. The major reward is awarded via rewardscreens in a similar manner to game within a game bonus in themarketplace today. The major reward is when the minor rewards earnedduring prior games or sessions are given a cash value.

While a player is participating in a reward, the pay table remainsconstant. Upon conclusion of the reward session, a new pay table will beassociated with the reward.

Reward Features

Four reward features are described in this section. They are Collection,Return rewards, Cash Drawing Rewards, and Draw Card. Each reward featureis broken into Minor Reward and Major Reward summarizes.

A collection reward feature awards unique and non-unique items that areto be collected as the Minor Reward and awards cash for the number ofunique items as the Major Reward.

The Minor Reward is based upon the Reward Pool Mechanism detailed above.The game sets the coin-in trigger that causes the machine to grant thecollection of an item. The player obtains their grant by choosing from aselection of objects presented to the player on a gamescreen. Thecollection of the item can be a unique item or a non-unique item. In theevent the item is unique, it is stored in the PSGS 70. The player canlook at the inventory of items and their worth at any point to in thegame. In the event that the item has already been earned, the machinetells the player that the item was a duplicate. The non-unique itemsearned are stored in PSGS 70, but may be held unavailable for thecustomer to review. The value of the items collected is displayed in theReward Feature Message area, which is described below.

The Major Reward is based upon the player earning the predeterminednumber of collection opportunities. Upon reset or inserting the card forthe first time, the machine 80 decides how many opportunities the playerwill have to earn unique items. This number is stored in the PSGS 70.The machine will examine how many opportunities a player has had, uponmeeting the criteria the machine will trigger the Major Reward. The PSGS70 stores how many times the player has had an opportunity, as well asthe number of opportunities the player will have to earn unique items.Based upon the number of items, the machine 80 will award a cash prizeto the customer through a series of screens, similar to a game Rewardround. Upon completing the award, the customer starts over collectingitems, and all Reward Pool Mechanisms and predetermined opportunitiesare reset to corresponding values.

The Return Reward Feature awards promotional credits that can beredeemed at a later date. The qualification for Return Rewards is theMinor Reward, and the winning and redemption of the promotional or extracredits occurs at a future date via the Major Reward.

The Minor Reward is based upon the Reward Feature Pool Mechanismdetailed above. The game 80 sets the coin-in trigger that causes themachine to grant the Return Rewards feature. Upon the trigger occurring,the player will be notified of their qualification and when they will beable to redeem the reward. The PSGS 70 stores the fact that the playerhas qualified for the Reward.

The Major Reward is based upon a player returning to the casino after aspecified period of time and placing their player tracking card in anappropriately configured game 80. Upon inserting the card, the machine80 presents a selection mechanism, for example a video wheel that hasmultiple values. The values on the wheel are provided by the PSGS 70.Upon spinning the wheel, the customer will be informed that they havewon a number of promotional credits redeemable at that time. In someembodiments the player must redeem the prize at that moment. The machine80 will update the PSGS 70 on the status of the player's redemption. Theplayer will then have the ability to play their promotional credits. Theplayer receives the credits through a series of screens reinforcing whythey received the credits.

The Cash Draw Rewards feature awards Cash Drawing Tickets, which can, beredeemed at future date for cash prizes during the Cash Drawing. Theawarding of Cash Drawing Tickets is the Minor Reward, and the CashDrawing Rewards where the tickets are awarded a value is the MajorReward. For example, upon inserting a player tracking card, the gamechanges one or more squares located on a game board from “Casino Night”to “Cash Drawing”. These squares are hit when a player hits a scatterpay triggering the game Reward, and than lands on a Cash Drawing squarelocated on the game board. Of course, the drawing tickets can beprovided to the player in other ways, but typically would include achance mechanism.

The Minor Reward is based upon the Reward Pool Mechanism detailed above.The game 80 sets the coin-in trigger that causes the machine to grantthe player an opportunity to win a number of Cash Drawing Tickets. Uponthe trigger occurring, the player will proceed to have an opportunity toearn a random number of tickets. The number of ticket earned is storedon the PSGS 70. The player has the ability to examine their inventory oftickets. Each ticket may be assigned a series of numbers that arerepresented on the ticket. In addition to the series of numberrepresenting the unique value of the ticket, the ticket also may have anindividual color assigned to the ticket by the player during the RewardFeature. The player can choose one of, for example, four availablecolors. There typically is a maximum number of Cash Drawing Tickets thatcan be earned before triggering the Cash Drawing Major Reward. If themaximum number is reached, the system 10 may limit the number of anyfuture tickets issued to the player until after the already issuedtickets have been redeemed.

The Major Reward is based upon the player landing on a specific spot ongame board during a machine Reward round. A scatter pay triggers themachine Reward round. Upon landing on the spot, the player gets toparticipate in a Cash Drawing Rewards. There can be, for example, fivelevels of prizes that can be won.

Beginning with the lowest prize, the machine 80 simulates a CashDrawing. If the machine 80 chooses a player's winning ticket, the valueis awarded to the player, using any conventional manner, and the playeradvances to the next level of prize. The winning ticket is eliminatedfrom future Cash Drawing Rewards. If the player does not have a winningticket, the player advances to the next level. Each level is repeated,upon completing all levels remaining tickets are declared non-winning,and the player collects the winnings and begins earning Cash DrawingRewards tickets all over again. All non-winning tickets are forfeited atthe conclusion of the drawing.

The Draw Card Reward is based upon the Reward Pool Mechanism detailedabove. The awarding of Draw Cards is the Minor Reward, and theredemption of Draw Cards for value occurs in the Major Reward.

The Minor Reward for the Draw Card is based upon the Reward PoolMechanism. The game sets the coin-in trigger that causes the machine togrant the Draw Card Tickets. Upon the trigger occurring, the machine 80will proceed to show a ticket drawn and placed on the game board. Thelocation and value of the Draw Cards are stored in the PSGS 70. Theplayer has the ability to view their game screen. In some embodiments,Draw Cards cannot be placed on the Cash Drawing square located on thegame board.

The Major Reward for the Draw Card is based upon the player landing on aspecific spot on game board during a machine Reward round. The machineReward round occurs on a scatter pay. Upon landing on the spot, theplayer wins an amount based upon the base game Reward. In addition tothe base game pay, the player gets to collect additional cash prizes forhaving a Draw Card-in that location. As a player moves past locationswith Draw Cards, the Draw Cards are removed from the game board.

Example Game Screen

FIG. 2 illustrates an example configuration 200 of a game screen thatcan be displayed on a machine 82 of the gaming machine 80 (FIG. 1). AReward Feature Messaging Area 210 is essentially a banner with messaginggraphics that change merchandising the Reward Features, Status in theReward Feature, Help Screens, Pay Table Screens, and other miscellaneousdetails described herein. The graphical messaging may be stored on themachine 80, and the PSGS 70 will signal the machine 80 when to displaythose graphics. The PSGS 70 can use any appropriate message or signalingprotocol between itself and the machine 80, such as the one describedbelow. Other areas of the game screen 200 include game reels 220, whichmay include 5 reels, 9 reels, or any other appropriate number, as wellas a messaging area 230 that presents data related to buttons and gamemeters. The information driving the messaging area 230 can come from thegame 80, the PSGS 70, or elsewhere on the architecture system 10 of FIG.1.

A Game Start Screen is a screen shown on the machine display 82 at thecommencement of a game. In some embodiments, the Game Start Screenmerchandises the Reward Feature, emphasizing the use of the player'scard. In addition, this screen will allow the non-carded player to viewa details screen, described below, as well as the pay table for theReward Feature. Upon insertion of the player card, the Reward FeatureMessaging 210 area will welcome the customer by name, and will begincommunicating their status in the Reward Feature. This communication isdescribed in more detail below.

The game played on the machine 80 may continually display information tothe player that summarizes their current Reward Feature Status in theReward Feature Messaging Area 210. The following messaging in Table 1are examples of what might be displayed:

TABLE 1 Status Action Message Idle Game No Play Attract message enticingplay Game Play No Card-In Entice message encouraging carded play GamePlay Eligible Card-In Messaging alternating between several graphicsCurrent List of Graphical Representation Items Collected Items arethrough the entire Reward round Prize Potential (Collect all 10 items towin $10,000)Game status information will be detailed further below.

Promotional concepts implemented in the PSGS 70 system are based on theto presumption that details about the player are known somewhere on thearchitecture 10. The details may be stored on the machine 80. Thesedetails may also be stored in the patron database 72 of the PSGS 70 orelsewhere on the architecture 10. The player will be identified to themachine 80 using the existing player tracking card and slot datacollection system. An example data flow through the PSGS is illustratedin FIG. 3. The diagram depicts the flow of messaging through thearchitecture 10 including the PSGS 70 when a player inserts theircard-into a machine. Examples illustrated in FIG. 3 include:

(1) A player inserts a player-tracking card with identifying card numberin a card reader 22 of the player tracking hardware 20.

(2) A Serial Machine Interface Board (SMIB) 28, such as that describedin U.S. Pat. No. 5,655,961 assigned to the assignee of the presentinvention and incorporated herein by reference performs low level numberchecking then forwards the card-in request to player tracking system 20.

(3) The player tracking system 20 confirms an active account status bychecking the player tracking card against data stored in thearchitecture 10, and then forwards an appropriate card-in message to thePSGS 70.

(4) The PSGS 70 looks up rewarding related data for that player andforwards information to the machine 80.

(5) The machine 80 processes reward information, making appropriateadjustments to game behavior.

(6) Promotional information presented to the player on the machine videoscreen 200 illustrated in FIG. 2, or on another screen shown on themachine display 82.

(7) At the start of a carded play session, a special card-in message ispreferably displayed in the Reward message area 210.

Player Identification Protocol

In some embodiments, all messages and transactions between the machine80 and the PSGS 70 of the architecture 10 of FIG. 1 are tracked byplayer card id as an identifier. The player-tracking system 20 validatesthe player card id for the PSGS 70. The PSGS 70 manages and stores thecard id for use by the machine and the PSGS. In some embodiments, allmessage packets include the player id.

A Card Reader Monitor 24 (FIG. 1) is a device or a function operated ona processor that acquires the same identification card strip informationand insert status that is seen by the player tracking SMIB 28. Thisdevice is used to double-check the player tracking system 20 card in andout operation. If the PSGS 70 sees either a Card Reader Monitor 24 cardout or a player-tracking 20 generated card out, the PSGS 70 will end aplayer's session. The PSGS 70 will not start a player session until itsees a card in from the Card Reader Monitor 24 and the player-trackingcard in. Upon receiving the first card in, the PSGS 70 starts a timer.Upon receiving the second card in, the PSGS 70 starts the session. Ifthe PSGS 70 does not receive the card in during the allotted time, thePSGS 70 will not start a session, and will request the customer tore-insert card.

One of the purposes of having the card reader monitor 24 is that itallows signals coming out of the hardware card reader to be read andused by other portions of the PSGS 70. The Card Reader Monitor 24provides a standard mechanism to detect and derive information fromplayer cards that is separate and distinct from existing playertracking/patron management systems.

In implementation the card reader monitor 24 includes a communicationsystem, such as a cabling system attached between the hardware cardreader to convert the output to, for example, a standard RS-232 format.The other end of this cable is then attached to a serial port on themachine 80. The card reader monitor 24 also includes a process, such asa software process that runs on a processor in the player trackingsystem 20 or on the machine 80, for example. This running processmonitors that RS-232 port, detects incoming data, decodes the data, andsends an appropriate message to the message controller interface betweenthe machine 80 and the PSGS 70.

Messages sent by the card reader monitor 24 can include, for examplecard in (with Card ID) card out (with Card ID), and abandoned card (withCard ID). After a message is created it is sent to the PSGS 70 to updatethe current status of the inserted player tracking card.

A “heartbeat” (periodic messages to ensure another component is still“alive”) is initiated by the game 80 or the PSGS 70 to ensure the Cardreader monitor 24 is still active. If, for any reason, that heartbeat islost, the Game 80 is signaled to disable PSGS 70 functionality. Adetailed description of a heartbeat implementation is described below.

The card reader monitor 24 may use power from the SMIB 28 for its uP,and power from the machine 80 serial port for optoisolation. In someparticular embodiments, if the player tracking card is successfullyinserted, the machine 80 will receive a packet from the card readermonitor 24 with the following format: “ISnnnnnnnnn.hh”, where Ascii ‘I’denotes card insertion detected by the reader switch or optoisolator,Ascii ‘S’ denotes detection of the card stripe “sync” character, ‘n . .. n’ are the numeric Ascii representation of characters ‘0’ through ‘9’encoded on the card. Up to 15 may be included, ‘.’ is the Asciidelimiter between the end of the card numeric data and the beginning ofthe check field, and ‘hh’ is the two-digit Ascii-Hex check field thatrepresents the exclusive-oring of the Ascii characters from the ‘S’ tothe ‘.’ inclusive. This will be used by the machine to verify thereception of a valid packet. On a failed insertion, the machine 80 willsee: “Ifx”, where ‘I’ denotes an insertion, ‘f’ denotes a failure, and‘x’ is a placeholder for an Ascii lower-case failure code letter: ‘c’denotes a failure of expected clock detection, ‘s’ denotes a failure ofexpected sync character detection, and ‘1’ denotes a failure of expectedlongitudinal redundancy check. When the card is removed from the readerunder any circumstances, the machine 80 will receive a signal including“R<cr>”, where Ascii ‘R’ denotes card removal detected by the readerswitch or optoisolator.

Sessions

A session begins as the PSGS 70 recognizing a player's card in the PSGS70 database 72, 74, or from the patron database of the player trackingsystem 40. The PSGS 70 recalls the player status in the reward feature.The player status is forwarded to the machine 80. The machine 80 beginsmanaging the player's progress.

A session ends upon the PSGS 70 receiving a card out signal from eitherthe player-tracking system or the Card Reader Monitor 24. However, if agame fails or the PSGS goes down the player's session will end.

For the best possible database accuracy, the updating of the playerdatabase from the Machine will be redundant, based upon, for example,four methods:

(1) Card—Out: This event causes the Machine 80 to update the PSGS 70 oncustomer status at the end of the customer's session.

(2) Timed: The PSGS 70 will poll the machine 80 on a timed basis. Thepolling will cause the machine to update the PSGS 70 with the playerstatus if applicable. The PSGS 70 will then update the database to storethe current information related to the player's session and progress inthe game. The Machine 80 will poll the PSGS 70 on a timed basis toverify that the PSGS 70 is still on-line.

(3) Minor Reward: Upon the Machine 80 triggering a Minor Reward, theMachine will poll the PSGS 70 with the outcome of the event.

(4) Major Reward: Upon the Machine 80 triggering a Major Reward, theMachine will poll the PSGS 70 with the outcome of the event.

In the event that PSGS loses connection with Machine 80, during idleperiods or prior to the insertion of a player card, the machine 80 willcontinue to operate in a mode that does not allow players to qualify forthe player-based Rewards. The machine 80 will offer to card players thesame features and benefits that are offered to non-carded players.

In embodiments of the invention, the machine 80 records all transactionsnecessary to update the PSGS 70 on all customers who have a card-inbefore the link failed. In the event that a player has card-insertedwith prior to link failure, the machine will need to keep informationspecific to that session stored and will need to update the PSGS 70 whenit comes back on-line. The machine 80 preferably has a capacity to store200 or more events related to player status in the Reward Feature. Anyinformation required by the PSGS 70 to make the Reward Feature workshould be saved in the stored events.

Message Structures

The PSGS 70 and the machine 80 communicate by sending messages betweenthemselves over a “PSGS Network” 90 illustrated in FIG. 1. The structureof the particular messages is implementation specific and may bedifferent from the examples shown herein.

In one example messaging system, the Message Type communicates theorigin of the sender. Machine Location and Machine Number representunique identifiers associate with the Machine 80. Timestamp places adate on each packet. Message Authentication validates the messagecontents and sender to ensure proper authorization for the information.Detail are illustrated in Table 2.

TABLE 2 Data Type Description Source Message Type Byte Unique MessageIdentifier Sender (constant) Sequence Number Byte Unique MessageIdentifier Sender Card Id Char [20] Unique Player Card Identifier SenderPlayer Acct Char [20] Unique Player Account Sender Number IdentifierMachine Location Char [20] Unique Machine Location PSGS IdentifierMachine Number Char [20] Unique Machine Identifier PSGS TimestampUndefined Troubleshooting and Disputes PSGS Message Authentic UlongValidates msg contents and Sender sender

Acknowledgement messages are replies to the sender, indicating thereception and validation of the transmitted message, such as illustratedin Table 3.

TABLE 3 Data Type Description Source Valid Message Byte Message typethat resulted in this Sender Type Ack Sequence Number Byte UniqueMessage Identifier Sender

Non-acknowledgement (Nak) messages are replies to the sender, indicatingthe partial reception or invalidation of the transmitted message, asillustrated in Table 4.

TABLE 4 Data Type Description Source Invalid Message Byte Message typethat resulted in this Sender Type Nak Sequence Number Byte UniqueMessage Identifier Sender

Reward enable and disable data structures describes control from PSGS toMachine enabling and disabling Rewarding Features. A communication checkmessage packet is used to verify connectivity between the machine 80 andthe PSGS 70.

Configuration Set messaging may include the following fields: FeatureIndependent Fields, Item Collection Reward Fields and Drawing RewardFields, These fields detail Reward operation parameters.

Script/Random Mode defines how the machine 80 is to award prize amounts.The scripted mode is a reward sequence where a series of graphical stepsresults in a predetermined outcome. The random mode is a random numbergenerator (RNG) call performed by the machine to determine the rewardoutcome. Minimum Reward Position assists the Machine in graphicallycommunicating to the player the start position in the Major Reward.Maximum Reward Position assists the Machine in graphically communicatingto the player the ending position in the Major Reward. Collection PoolMinimum is the minimum position for the Reward Pool Mechanism.Collection Pool Maximum is the maximum position for the Reward PoolMechanism. The Collection Pool Increment Rate is a percent of coin-inused to fund the final prize amount. Examples are illustrated in Table5.

TABLE 5 Data Type Description Source Script/Random Mode Byte FlagControlling Collection PSGS Random or Database Script Method MinimumReward Uint Lowest Absolute Position in PSGS Position Collection RewardMaximum Reward Uint Highest Absolute Position in PSGS PositionCollection Reward

Script/Random Mode defines how the Machine 80 is to award prize amounts.The scripted mode is a reward sequence where a series of graphical stepsresults in a predetermined outcome. The random mode is a random numbergenerator (RNG) call performed by the machine to determine the rewardoutcome. An example message protocol is illustrated in Table 6.

TABLE 6 Data Type Description Source Script/Random Flag Byte FlagControlling Drawing Random PSGS or Database Script Method

Script/Random Mode defines how the Machine 80 is to award prize amounts.The scripted mode is a reward sequence where a series of graphical stepsresults in a predetermined outcome. The random mode is a random numbergenerator (RNG) call performed by the machine to determine the rewardoutcome. Minimum Draw Card Rewards Position stores minimum location ofthe card on the game board. Maximum Draw Card Rewards Position storesmaximum location of the card on the game board. An example messageprotocol is illustrated in Table 7.

TABLE 7 Data Type Description Source Script/Random Mode Byte FlagControlling Draw Card PSGS Random or Database Script Method Minimum DrawCard Uint Lowest absolute position in PSGS Reward Position LocationReward Maximum Draw Card Uint Maximum absolute position in PSGS RewardPosition Location Reward

Card-in response messaging may include the following fields: FeatureIndependent Fields, Item Collection Reward Fields, and Drawing RewardFields. These fields detail Reward status and parameters. Player NickName or First Name is used in the Reward Feature Messaging Area towelcome the guest. The Player Last Name is used to continue to createunique identifiers for the PSGS. Player tier is a quality ranking.Currently, this field is not used but may be used in futureapplications. Player ID is the unique number identifier for the PlayerTracking System. Pin is the unique number that the player uses to accesstheir account. Pin Lock Count is used to assist with managing theMachine and the PSGS in the event that PIN entry has failed. An examplemessage protocol is illustrated in Table 8.

TABLE 8 Data Type Description Source Player Nick Name or Char [15]Player Preferred Player Tracking First Name Name System Player Last NameChar [15] Player Last Name Player Tracking System Player Tier BytePlayer Quality PSGS Ranking Player ID Ulong Unique Database PSGSIdentifier Pin Char [11] Player Pin Pad Player Tracking Entry CodeSystem Pin Lock Count Byte Account Tamper Player Tracking ThresholdSystem

The Current Position is the player's location in the collection Reward.Total Number of Unique Items is the maximum number of opportunities theplayer will have to collect unique items. The Final Prize Award TableIndex points the machine to the player specific pay table. The pay tableis located on the machine. This is the pay table associated with thisReward Feature. Collection Count is the number of unique items in aplayer's collection. Collection Array is the indexed value of earneditems. Collection Pool Current is the current pool amount based upon theplayer's coin-in and associated incrimination, The Collection PoolThreshold is the target position to trigger the Major Reward. This valueis created by the Machine and stored by the PSGS. An example messageprotocol is illustrated in Table 9.

TABLE 9 Data Type Description Source Current Position Uint CurrentPlayer Position in PSGS Reward Total Number of Byte Maximum Number ofPSGS Unique Items Opportunities to Earn Unique (NOU) Items in CollectionReward Collection Count Byte Number of items in player PSGS collectionCollection Array Byte Current Items in Collection PSGS [NOU] (items areindexed) Collection Pool, Uint Current Position in Item PSGS CurrentCollection Pool Collection Pool, Uint Target Position in Collection PSGSThreshold Pool Drawing Scripts To be Determined PSGS Collection Pool,Uint Minimum Position in Collection PSGS Minimum Reward Pool CollectionPool, Uint Maximum Position in Collection PSGS Maximum Reward PoolCollection Pool, Uint Percent of coin-in allocated to PSGS IncrementRate Item Collection Pool (.0001 to .9999) Script Index Byte Playersposition in script PSGS

The Return Reward Status from the PSGS system 70 to the machine 80signals the machine 80 to know whether the player has a pending ReturnRewards or whether the player has been awarded a value. Return RewardCredit Value is the award given to the player based upon the outcome ofthe Award Table and associated probabilities. The Return Rewards AwardTable is the award and the probability of winning the award in thisfeature. This table is downloaded and associated with the player eachtime the redeem the Reward. The Relative Time to Availability is theminimum time required before the player is eligible to redeem theirReturn Rewards prize.

Random Mode defines how the Machine 80 awards prize amounts. The randommode is a random number generator (RNG) call performed by the machine todetermine the reward outcome. The Return Rewards Award Table is theaward and the probability of winning the award in this feature. Thistable is downloaded and associated with the player each time the redeemthe Reward. Return Rewards Pool Minimum is minimum pool value set forthe Reward Pool Mechanism, and the Return Rewards Pool Maximum is themaximum pool value set for the Reward Pool Mechanism. The Return RewardsPool Increment Rate is the contribution of coin-in to fund the Reward.An example message protocol is illustrated in Table 10.

TABLE 10 Data Type Description Source Return Reward Status Byte 0 =Pending, 1 = PSGS Return Reward Credit Uint Awarded Value Earned PSGSValue Return Rewards Ulong[ ][ ] Award and Weight Table PSGS Award TableRelative Time to TBD The Minimum time PSGS Availability required beforeplayer is eligible for Return Rewards Return Rewards, Uint Minimum PoolAmount PSGS Pool, Minimum in Return Rewards Pool Return Rewards, UintMaximum Pool Amount PSGS Pool, Maximum in Return Rewards Pool ReturnRewards, Uint Percent of coin-in to PSGS Pool, Increment Rate triggerReturn Rewards feature (.0001 to .9999)

The Current Chances are the number of chances based upon tickets earned.The Chances per Drawing sets the maximum number of tickets earned, whichif achieved would shut down the Minor Reward feature in the Cash DrawingReward feature. The Drawing Award Table Index is the pay table valuesused in the redemption of tickets for prizes. This table is located onthe machine and is associated with each player. A player must completethe Major Bonus before a new pay table index can be associated with theplayer. Chances Array is the accumulated chances for drawing, which areidentified by eight digit numbers and characterized by player chosencolor. Chance Pool Current is the current value in the pool. The ChancePool Threshold is the target value of the pool, which was set by theMachine and stored by the PSGS. The Cash Drawing Pool Minimum is theminimum position for the Reward Pool Mechanism. The Cash Drawing PoolMaximum is the maximum position for the Reward Pool Mechanism. The CashDrawing Pool Increment Rate is the percent of coin-in used to fund theaward table. An example message protocol is illustrated in Table 11.

TABLE 11 Data Type Description Source Current Chances Byte Number ofChances in Drawing PSGS Reward Chances Per Byte Maximum number oftickets PSGS Drawing (CPD) allowed Drawing Award Byte Points to activepay table for PSGS Table Index this player. The pay table is located onthe machine. Chances Array Byte Accumulated Chances for PSGS [CPD]drawing (chances are identified [ID][C] by 8 digit number and color)Chance Pool, Uint Current Position in Chance Pool PSGS Current ChancePool, Uint Target Position in Chance Pool PSGS Threshold Drawing ScriptsTo be Determined PSGS Cash Drawing Pool, Uint Minimum Position in ChancePSGS Minimum Pool Cash Drawing Pool, Uint Maximum Position in ChancePSGS Maximum Pool Cash Drawing Pool, Uint Percent of coin-in allocatedto PSGS Increment Rate Chance Pool (.0001 to .9999) Script Index BytePlayers position in script PSGS

The Current Position is the location of the player on the game board.Location Table is the value and geographical position of the Draw Cardson the game board. Location Pool Current is the current value in thepool. The Location Pool Threshold is the target value of the pool, whichwas set by the Machine and stored by the PSGS. The Draw Card PoolMinimum is the minimum value used in the Reward Pool Mechanism. The DrawCard Pool Maximum is the maximum value used in the Reward PoolMechanism. The Draw Card Rewards Pool Increment Rate is the contributionof coin-in to fund the Reward. An example message protocol isillustrated in Table 12.

TABLE 12 Byte Data Type Description Source Current Position Uint CurrentPlayer Position in PSGS Location Reward Location Table Byte[ ][ ]Location value and graphical PSGS representation Draw Card Byte Pointsto active pay table for this PSGS Award Table player. The pay table islocated Index on the machine. Draw Card Pool, Uint Minimum Position inDraw Card PSGS Minimum Pool Draw Card Pool, Uint Maximum Position inDraw PSGS Maximum Card Pool Draw Card Pool, Uint Percent of coin-inallocated to PSGS Increment Rate Chance Pool (.0001 to .9999) LocationPool, Uint Current Position in Item PSGS Current Collection PoolLocation Pool, Uint Target Position in Item PSGS Threshold CollectionPool

Because the Machine 80 has no internal notice that the player hasremoved his card from the player-tracking panel, the database mustrequest it. This message need not have any particular data fields.

Card-out event messaging may include the following fields: FeatureIndependent Fields, Item Collection Reward Fields, and Drawing RewardFields. These fields detail Player-based Reward status and parameters.

The Current Position is the player's location in the collection Reward.Collection Count is the number of unique items in a player's collection.Collection Array is the indexed value of earned items. Collection PoolCurrent is the current pool amount based upon the player's coin-in andassociated incrimination. The Collection Pool Threshold is the targetposition to trigger the Major Reward. This value is created by theMachine and stored by the PSGS 70. An example message protocol isillustrated in Table 13.

TABLE 13 Data Type Description Source Current Position Uint CurrentPlayer Position in PSGS Reward Collection Count Byte Number of items inplayer PSGS collection Collection Array Byte Current Items in CollectionPSGS [NOU] (items are indexed) Repeat Items Uint Current Session TotalNumber Machine of Repeat Items Collection Pool, Uint Current Position inItem PSGS Current Collection Pool Collection Pool, Uint Target Positionin Item PSGS Threshold Collection Pool

The Return Reward Status lets the machine 80 know whether the player hasa pending Return Rewards or whether the player has been awarded a value.Return Reward Credit Value is the award given to the player based uponthe outcome of the Award Table and associated probabilities. TheAbsolute Time to Availability is the minimum time required for theplayer to redeem the prize. An example message protocol is illustratedin Table 14.

TABLE 14 Data Type Description Source Return Play Credit Uint ValueEarned PSGS Value Time Available Byte First time, which player can PSGSredeem Return Rewards Player Accept Byte Field Indicating Customer ReadPSGS and Accepted Instructions

The Current Chances are the number of chances based upon tickets earned.Chances Array is the accumulated chances for drawing, which areidentified by eight digit numbers, and characterized player chosencolor. Chance Pool Current is the current value in the pool. The ChancePool Threshold is the target value of the pool, which was set by theMachine and stored by the PSGS. An example message protocol isillustrated in Table 15.

TABLE 15 Data Type Description Source Current Byte Number of Chances inDrawing PSGS Chances Reward Chances Byte Accumulated Chances for PSGSArray [CPD][ID][C] drawing (chances are identified by 8 digit number,and color) Chance Pool, Uint Current Position in Chance Pool PSGSCurrent Chance Pool, Uint Target Position in Chance Pool PSGS Threshold

The Current Position is the location of the player on the game board.Location Table is the value and geographical position of the Draw Cardson the game board. Location Pool Current is the current value in thepool. The Location Pool Threshold is the target value of the pool, whichwas set by the Machine and stored by the PSGS. An example messageprotocol is illustrated in Table 16.

TABLE 16 Data Type Description Source Current Uint Current PlayerPosition in PSGS Position Location Reward Location Table Byte[ ][ ]Location value and graphical PSGS representation Location Pool, UintCurrent Position in Item Location PSGS Current Pool Location Pool, UintTarget Position in Item Location PSGS Threshold Pool

Reward event messaging may include the following message fields: FeatureIndependent Fields, Item Collection Reward Fields, and Drawing RewardFields. These fields detail Player-based Reward status and parameters.

The Current Position is the player's location in the collection Reward,Collection Count is the number of unique items in a player's collection.Collection Array is the indexed value of earned items. Collection PoolCurrent is the current pool amount based upon the player's coin-in andassociated incrimination. The Collection Pool Threshold is the targetposition to trigger the Major Reward. This value is created by theMachine and stored by the PSGS. An example message protocol isillustrated in Table 17.

TABLE 17 Data Type Description Source Current Position Uint CurrentPlayer Position in PSGS Reward Collection Count Byte Number of items inplayer PSGS collection Collection Array Byte Current Items in CollectionPSGS [NOU] (items are indexed) Repeat Items Uint Current Session TotalNumber Machine of Repeat Items Collection Pool, Uint Current Position inItem PSGS Current Collection Pool Collection Pool, Uint Target Positionin Item PSGS Threshold Collection Pool

The Return Reward Status lets the machine 80 know whether the player hasa pending Return Rewards or whether the player has been awarded a value.Return Reward Credit Value is the award given to the player based uponthe outcome of the Award Table and associated probabilities. TheAbsolute Time to Availability is the minimum time required for theplayer to redeem the prize. An example message protocol is illustratedin Table 18.

TABLE 18 Data Type Description Source Return Play Credit Uint ValueEarned PSGS Value Time Available Byte First time, which player can PSGSredeem Return Rewards Player Accept Byte Field Indicating Customer ReadPSGS and Accepted Instructions

The Current Chances are the number of chances based upon tickets earned.A Chances Array is the accumulated chances for drawing, which areidentified by, for example, eight digit numbers, and characterized by aplayer chosen color. Chance Pool Current is the current value in thepool. The Chance Pool Threshold is the target value of the pool, whichwas set by the Machine and stored by the PSGS. An example messageprotocol is illustrated in Table 19.

TABLE 19 Data Type Description Source Current Byte Number of Chances inDrawing PSGS Chances Reward Chances Byte Accumulated Chances for PSGSArray [CPD][ID][C] drawing (chances are identified by 8 digit number,and color) Chance Pool, Uint Current Position in Chance Pool PSGSCurrent Chance Pool, Uint Target Position in Chance Pool PSGS Threshold

The Current Position is the location of the player on the game board.Location Table is the value and geographical position of the Draw Cardson the game board. Location Pool Current is the current value in thepool. The Location Pool Threshold is the target value of the pool, whichwas set by the Machine and stored by the PSGS 70. An example messageprotocol is illustrated in Table 20.

TABLE 20 Data Type Description Source Current Uint Current PlayerPosition in PSGS Position Location Reward Location Table Byte[ ][ ]Location value and graphical PSGS representation Location Pool, UintCurrent Position in Item Location PSGS Current Pool Location Pool, UintTarget Position in Item Location PSGS Threshold Pool

The Machine 80 manages all graphical messages and the triggers to causethose messages will typically be managed by the PSGS 70. In the eventcommunication between the PSGS 70 and the Machine 80 is lost, the lossof communication should cause a message error to display a message thatthe Player Based Reward offering is unavailable. Message errors andcommunication can take any appropriate form. In addition, some gamedesigns could require that the Reward Message Area be capable of movingaround on the screen.

Unique Machine identification

As mentioned above, the architecture 10 can include (and typically willinclude) several machines 80 coupled to the PSGS 70 and the datainterface 60. One way to uniquely identify the machines 80 is to includea non-volatile memory, for example an EEPROM that can be coded with aunique serial number. In some embodiments, the EEPROM may store anInternet Protocol address. The non-volatile memory may be changed orupdated as the machine numbers 80 change.

In other embodiments, the Machine 80 may include a “dongle” or otherdata port connection that includes codes to make the machine 80 uniquelyidentified. Initialization of machines 80 according to these embodimentsmay be conducted by configuring the address of the slot machine byinstalling a UID (Universal ID) Dongle on a parallel port of the machine80. The Dongle will fix the TCP/IP address to prevent loss of addressingwhile, for example, replacing the machine electronics. The machine willread the Dongle on reset. The PSGS 70 may be provided the TCP/IP addressthrough a manual entry process.

Advantages of the Dongle method for maintaining TCP/IP addressing at theslot machine are that it assures the system of having a unique id forthe slot machine 80. It also allows the architecture 10 to embed acommunication encryption key on to the Dongle. Such a structure issimple to setup in the field.

To prevent duplicate TCP/IP addresses, due to the casino networkconfiguration, the architecture 10 may require additional network andsoftware components to be added to the casino's network level.

In addition to standard TCP/IP security, the dongle can include aPublic/Private Key Encryption (PKE) that can be accessed by the machine80. Authenticating messages are sent between the machine 80 and the PSGS70. PKE may be a number of 128-byte encryption or better. A SecureHashing Algorithm or another acceptable algorithm can be used forhashing. The machine 80, via the dongle and the PSGS 70 can verifypackets with each others' public and private keys. Of course, othersecurity methods can be implemented provided they accomplish therequisite level of security needed. An example of a security flowbetween the PSGS 70 and the machine 80 is illustrated in FIG. 5.

Downloading Machine Pay Tables

Using the architecture 10 system described above, it is possible to addan additional element to the PSGS 70. Specifically, machine pay tablesthemselves can be downloaded from a central location and into the gamingdevice 80. Pay tables relate the outcome of a game played and thebenefit received by the player for the particular game outcome.

Gaming devices 80 can include a standard pay table for a game, i.e., thepay table that is the standard pay table offerings for that game. Inaddition, one or more (or all) of the elements within the pay table canbe changed. Once changed, they can be downloaded into a gaming device 80to become the new game table for a particular game.

Game tables can be changed for a number of reasons. For instance theycan be changed for different times of the day. Also, they can be changedfor specific promotions. The machine pay tables can also be changed forindividual players. For instance, a first set of game pay tables can becreated for a player with no detail history. Then, as more is learnedabout the player's style, habits, preferences, skill level, etc., forexample the data stored by fields in the patron database or the playertracking database or other database, then the game tables can bemodified. Once modified, the PSGS 70 can ensure that the modified paytable is downloaded to the game for the player. In one embodiment, whena player identifies himself or herself by inserting a player trackingcard, the PSGS 70 retrieves the personalized machine pay table anddownloads it to the machine at which the player is playing. Then, thegaming device changes its current pay table to the one just loaded bythe PSGS 70, such that the gaming table is personalized for that player.

As one can imagine, countless variations in modifying machine tables arepossible. The PSGS 70 may modify machine paytables at games to which itis connected every hour. Therefore, a particular machine outcome at 5:00am may be different from one at 11:00 pm. Additionally, if a playerknown to the PSGS is playing a machine at 5:00 am, the PSGS 70 can beprogrammed to either override the standard “modified” pay table, or toload the pay table that has been “created” for that particular player.It is also possible to change the paytable to the player specific paytable at some times and not at others. For instance, it is possible togive a player the highest (or lowest) possible payback between eitherthe standard machine paytable or the personalized pay table.

Even further, it is possible to have modified pay tables for eachindividual game on a machine 80. For instance, pay tables can bemodified for games at a first casino, but not at a second casino. Or,pay tables can be modified for a particular game at a casino based onthe game's physical location. In short, the PSGS 70 control of modifiedgame tables can extend down to the level of a different pay table for aplayer for each and every single game to which the PSGS 70 is connected.However, there may be too much overhead in keeping so many modified paytables for each of the players, and keeping modified pay tables per gametype for particular players may be an acceptable level ofcontrol/service for the overhead involved.

Authenticating a Game to the PSGS System

Another part of initializing the gaming machines concernsauthorization—i.e., is the machine 80 allowed to communicate to thedatabases connected to the PSGS 70, and is the game player recognized bythe PSGS system.

Each machine 80 authenticates with a PSGS 70 database when it powers up.In one embodiment, a message controller sends an XML machineauthentication message from the gaming machine to the PSGS server 70.Next, the PSGS 70 performs lookups, and cross-references a machineidentification, casino identification, game identification, etc. withthe PSGS database illustrated in FIG. 1 or 2.

More than one method is possible. In one embodiment, the PSGS 70 repliesthat the gaming device 80 cannot be identified, and then the machinecannot enable PSGS 70 functionality. The game 80 may continue tofunction normally as a normal slot machine, but will not have PSGS 70specific features. In another method, the PSGS 70 may add a trustedgame's identity to the list of valid games when the game 80 connects tothe server.

The PSGS 70 is a secure closed system that includes of a server and aseries of client Machines 80. Communication between the PSGS 70 and themachine clients 80 can be conducted utilizing an industry standardformat of XML-RPCs and can be encrypted using the SSL protocol.

A first level of authentication occurs when an initial connectionattempt is made between the Machine 80 and the PSGS 70. If the Machine80 has a valid public key, which corresponds to the server's privatekey, then access is granted. If it does not have such a key, then theauthentication attempt is logged and the client machine is denied accessto the PSGS 70.

In some very secure embodiments, to further enhance the security of thesystem, each client machine 80 must contain a valid entry in the PSGS 70(i.e. it must be registered with the server). If so desired, the systemadministrator can configure the system to allow for machineself-registration. If this option has been enabled, on start-up the PSGS70 will accept the credentials of the requesting machine 80 and make theappropriate entries in the PSGS 70 database.

An example startup process is as follows: At machine start-up themachine 80 sends a Machine Authentication message from a MessageController (MC) to the PSGS 70. On receipt of the message, the PSGS 70decodes the message, extracts necessary key information, and attempts adatabase lookup within the PSGS 70 database. If successful, the dataretrieved from the database is utilized to construct a Machine Transfermessage that is sent from the server 70 back to the MC on the sendingmachine 80. This message can contain pertinent location informationaldata (for example, positional data on the casino floor, whether or notPSGS functionality is enabled on this machine, casino specific art andsound, target souvenir information (position, description, value, etc.)The message is used to initialize the game on the machine 80 withspecific parameters that customize the look, feel, and functionality forthe casino property. If unsuccessful and self-registration is enabled,then the server 70 accepts the credentials of the machine 80 andutilizes them to make the appropriate entries in the PSGS database. Itthen grants access and sends back necessary configuration data. Ifinstead self-registration is disabled, then the server will deny accessto the PSGS 70.

Players may also have to be identified to have games that interact withthe PSGS 70. Player identity, as described above, is gathered from aplayer tracking card that is inserted or otherwise read by the gamingdevice. Once the player identity is known, the PSGS 70 checks theidentity with players who have data previously stored in the PSGS 70.Additionally, the PSGS 70 may contact other data sources that areconnected to the PSGS but not necessarily stored in the PSGS to verifythe player's identity, before that the particular player is allowed toconnect to the PSGS system.

Even if the player identification data does not match exactly, forexample an address or other data may have changed, the PSGS 70 can stillallow the player to connect to the PSGS. In some embodiments, a databasein the PSGS 70 is automatically updated with the new or changedinformation.

Database Structure for Multiple Resort Groups and Multiple Casinos

One or more databases stored in the PSGS 70 have been structured suchthat a single instance database can be utilized in many situations—suchas in the following scenarios a single casino, a resort group consistingof multiple casinos, or a central hosting facility serving multipleresort groups and/or single entity casinos.

In one implementation, the casino can include a bank of machinescommunicating with the PSGS 70, which works well. If, for example, aspacious casino has a centralized data facility, all of the slotmachines in Casino A and all of the slot machines in Casino B cancommunicate with a centralized data facility. Alternatively, acentralized facility could be separately hosted. In this scenario, aseries of small independent casinos that are distinct and separate canall communicate with the central hosting faculty. They wouldn't have theexpenditures of the data of the centralized hardware in the server room.Although the machines could all tie in to the centralized facility, asfar as the casino patrons are concerned, they're going to seeinformation and content specific to that casino, even though there maybe data for more than one, or several, casinos stored in the centralfacility.

Each of the records or groups of records could be encrypted separately,with their own keys. Only the casino with the proper key could retrievethe proper data.

In some embodiments the database could be a PostGres operating on aLinux server.

An example single casino layout is illustrated in FIG. 6. Under thisscenario, an individual casino possesses a single PSGS system (whichcould, for instance, include a WWW server, an application server, and adatabase server) and hosts it within their facility. Any number ofgaming devices within that property can be connected to and communicatewith that specific PSGS server. System maintenance, scheduling, andconfiguration (for both the server and the individual gaming devices)can be performed through system maintenance web pages hosted on the PSGSserver. User and patron administration (databases coupled to the PSGS70) can be performed through web pages hosted on the PSGS server.Reporting can be also performed by this single PSGS server. Also,encryption in the database is performed using keys specific to thatcasino property.

An example multi-property configuration is illustrated in FIG. 7. Underthis scenario, the PSGS system 70 is configured to support a singleresort group of multiple casinos, illustrated as 310, 320. A resortgroup is an entity that maintains control over one or more casinoproperties. Each casino 310, 320 within the resort group meets thedefinition of a casino property under the previous scenario. Gamingdevices from more than one property within a group are connected to andcommunicate with a specific, single PSGS server 70 hosted at a centralresort group facility. System maintenance, scheduling, and configuration(for both the server 70 and the individual gaming devices), and for allproperties within that group can be performed through the systemmaintenance web pages hosted on the resort group PSGS server 70. Userand patron administration can be performed via web pages hosted on thePSGS server for all properties within that group. Reporting can likewisebe accomplished from this single PSGS server for all properties in thatresort group. Encryption in the database can be performed using keysspecific to that casino property or (if configured) with a key specificto the entire group. Each individual casino property, if configuredcorrectly, can independently configure and manage their individualassets. Each individual casino property, if configured in such afashion, can be considered to be working in a virtual serverconfiguration. Casinos have access to all patron management, machinemanagement, and server management functions just as if they wereoperating on their own individual server.

Another multiple property configuration is illustrated in FIG. 8. Inthat figure, multiple properties 330, 340 are serviced by a centralhosting facility 325 including the PSGS server 70. Under this scenario,the PSGS servers 70 are configured to support multiple casinos and/orresort groups. Servers need not be located at the resort groups and/orcasinos, 330, 340, but instead may be located at a central hostingfacility. All other functionality as provided by the previousconfigurations is still provided. This scenario frees customers fromcost and responsibility of maintaining and servicing day-to-dayoperations on server equipment.

Enhanced Messaging Capability

Enhanced messaging defines the messaging between the PSGS system 70 andthe gaming device 80. In some embodiments, the PSGS server 70communicates to a message controller 84 (MC), which is a process runningon the machine 80, via XML PC. This is functionally illustrated inFIG. 1. In turn, and in some embodiments, the message controller 84communicates to the game via Remote

Method Invocation (RMI).

The message controller 84 acts as the “Traffic Cop” receiving,translating, and routing messages to the intended recipients. Itsprimary responsibility is to offload message processing from the game,freeing it to handle all game related activities.

When messages are received, the message controller 84 determines therouting for the message type, translates the message for respectivereceiver, and sends the translated message.

In some embodiments, the message controller 84 runs separately from thegame machine 80, is started prior to game, bonus engine, etc. utilizingcurrent AGPx start-up process, automatically restarts and re-establishescommunications if it is terminated abnormally, and is responsible forreceiving and dispersing messages to/from authorized/intended processes.

The gaming machine 80 may include a server, such as PostgreSQL, Tomcat,etc., and may include a LOL (Local Online) Card Reader Monitor, asdescribed above. In some embodiments, the game machine 80 registersitself at start up with the PSGS server 70 via a message structure,accepts registrations from locally running processes (game, card readermonitor, etc.), utilizes the pre-existing game messaging format whencommunication with the game, and utilizes an industry standard XML basedmessage format between the MC and the server processes.

A heartbeat, described above, can be maintained between the gamingmachine 80 and the PSGS server 70, as well as between the messagecontroller 84 and all other registered processes.

In some embodiments, the message controller 84 can function in twomodes: normal, where all mandatory processes are present; where at leastone mandatory process is missing and the message controller 84 isstarted in such a fashion to allow simulation.

Message Protocols

The following describes the messaging protocols utilized internally,between the message controller 84 and the gaming machine 80, andexternally, between the message controller 84 and the PSGS server 70,within the architecture 10.

The message format between the game machine 80 and the messagecontroller 84 is dictated by the current message format serializedmessage format. Communication between the message controller 84 and thegame is via RMI

(Remote Method Invocation).

The message controller 84 will maintain an open messaging format toallow external applications the ability to interface with, and transmitmessages to the gaming device for processing, as well as a closed formatthat would not be provided to outside parties, which will ensureintegrity of the gaming system.

The XML format and protocol (XML-RPC) can be utilized by systemsdeveloped in languages other than Java.

All messages between the message controller 84 and external processesare preferably encrypted utilizing SSL. The message controller 84 willcache only a limited number of messages at the local level, becausecaching a large amount could be unsafe due to the possibility that aplayer could actually hit numerous bonus events and or rewardredemptions during a communications failure. Under such a scenario, aplayer could in fact redeem his/her winnings then move to anothermachine and resume play. The PSGS 70 system would be unaware that theplayer had redeemed the awards and would resume play at the point wherecommunications had failed. This, in effect, would provide the playerwith the possibility of redeeming rewards twice. With that in mind, onlya very limited number of messages are allowed to go unacknowledged bythe server before PSGS functionality shall be disabled.

If the PSGS 70 server does not respond before the message limit isreached, a message will be sent to the machine 80 disabling PSGS 70functionality due to server non-availability. In case of a power failureon the game machine 80, the message controller 84 should be able toretain the message log and resynchronize with the server once it isavailable.

Many different message types are possible between the game machine 80and the PSGS server 70, such as the following example message types:

Acknowledgment (PSGS)

Alarm Message (Game)

Alarm Message With Value (Game)

Bonus Award (PSGS)

Bonus Redemption (PSGS)

Button Message (Game)

Command Message (Game)

Connect Message (Game)

Credit Message

Game State Message

Heat Beat

Keep Alive

Machine Authentication (PSGS)

Machine Transfer (PSGS)

Message (Base)

Message Filter

Mouse Message (Game)

Patron Authentication (PSGS)

Patron Bet (PSGS)

Patron Bet Response (PSGS)

Patron Transfer (PSGS)

Promotional (PSGS)

Random Draw (Game)

Registration (PSGS)

Server Error (PSGS)

Session Begin (PSGS)

Session End (PSGS)

Session Transfer (PSGS)

XML Message (Base)

External Data Mining/Dynamic Content Generation

Using embodiments of this invention, dynamic content can be delivered toa game 80 that is based on specific player and/or casino preferences. A“my calendar” concept, which is a calendar that is tailored to aparticular game player is a natural outgrowth of this dynamic datamining process.

Utilizing this approach, the PSGS 70 would be granted access to externaldata sources through in-house integration efforts (providing directaccess to data) or through traditional screen-scraping techniques wheredata is derived from published sources, such as predefined web pages.

Examples of such integrations include: a tie in to the Sports Bookmarket, which would provide a way of filtering data, such as displayingsports data on the gaming screen (or an area of the game screen) to aplayer of a gaming device in real time, while the player is in the midstof slot (or other game) play. This could take the form of: eventstart/finish/game outcomes, win notifications, etc., i.e., displayingthe notifications on the game screen, and bringing this data to theplayer's attention in the form of banner messages or pop-ups. The tie incould become a two-way operation and bets could be taken for events w/ohaving the player leave the comfort of his/her slot machine. Oncebetting information was placed on the machine display 82, bet buttonscould accept a player's input and cause the bet to be made. Funds couldbe debited from the meters on the gaming machine 80, or from apre-established credit line (or deposit account) with the casino.

A tie into other areas of casino operations could also be accomplished.Examples of these could be announcements of: upcoming bingo sessions,upcoming future and results of past keno games, availability of pokerseats in poker rooms, restaurants/show reservations.

One appealing aspect of this customization is that through the use of aplayer tracking card, the casino knows exactly who and where the cardholder is, and can target a message directly to the card holder . . .and not broadcast the message to an entire casino or to an entire bankof machines.

With a two-way flow of data between the gaming machine 80 and the PSGS70, the architecture 10 can provides for, for example, makingreservations for dining/events by using the gaming screen, checking aplayer club status, etc by using the gaming screen, and checking airlineflight status by using the gaming screen, etc.

By extending this data mining/integration concept onto the PSGS server70, the ability to link these systems together is enhanced, whichprovides the player with a “portal” into their casino/gaming experience.

An example PSGS system 70 can consist of a server (or series of servers)connected to a series of slot machines, as described above withreference to FIG. 6. Additionally, a secondary data mining/routingprocess 400, such as a system illustrated in FIG. 9 is installed on thePSGS server 70 and operates on an application server to access externaldata sources, mine the available data, and bring it back to the PSGS 70for formatting and display.

In some embodiments, a dynamic content generator 76 (FIG. 1) operates onthe PSGS server. When directed, the dynamic content generator 76 wouldinitiate a servelet, for example, which would query an external datasource, build up the content and bring it back and display it.

The dynamic generator 76 could filter information before providing tothe screen of the gaming device. In one embodiment, a “my calendar”button could appear on the gaming screen 82 that, when selected, causesthe dynamic content generator 76 to get public and private events,format them, and display a calendar for the player.

To generate the calendar, or any other outside content, the dynamiccontent generator 76 could go to any external source for data content.In addition, the data could be made to flow in two directions, so thatthe player could generate data that is delivered to the PSGS 70 networkor to other connected networks. For instance, the gaming device could belinked to a casino's sports book operation and bring over some sportsbook information, including game scores, etc. The player could placebets and the bets placed with a casino's sports book. A player couldhook into a scheduling system for poker tables so that when a pokertable that came available, the table could get pushed to the player anda notification would appear on the player's game screen. Show, dinner,or transportation reservations could be made.

In another embodiment, a player could check into a hotel before theplayer's room was ready. Then, after the player inserted his or her cardin the gaming device 80, the PSGS 70 system could communicate with thehotel open room system, and could send a message to the player when hisor her room was ready, and even specify the room number or anyadditional information, for instance.

Such notices could be placed on a particular portion of the game screen82, for instance, or could be made into a pop-up message that appearsover the screen. Of course, the popup would not interfere with anexisting game, such as by waiting until the end of a turn or a gamebefore popping up on the screen.

FIG. 10 illustrates another method of connecting the PSGS to a websiteexternal from the game network.

Currently, games and gaming systems operate in closed environment and donot allow outside content to be displayed or allow for dynamicinformation and content. The idea of having a system like above is thatit allows for other systems to “speak” to the game using a communicationprotocol such as XML. As mentioned above, some of the benefits of thistype of application are listed below: streaming information personalizedto the player's tastes. I.e. streaming stock quotes, sports scores,allowing a customer to make sports wagers on the game. For instance, aticket printer, known in the art, could print the sports betting ticketand bill valuator could redeem the winning ticket. Such a system couldnotify the customer of upcoming bingo sessions. Such a system could takekeno wagers and allow the customer to review past and current results. Aticket printer could print the ticket and the validator could redeem theticket. In such a system the customer could be notified of a poker roomtable opening up and their status on the wait list. The customer couldaccess a calendar of events, such as that illustrated in FIG. 11. Thecalendar could detail events the public is aware of and private inventsthat are invite only, for instance.

The customer could access information about their points, comps, andcash back. The customer could make and review reservations for dinning,rooms, poker tables and special events. The system could allow forplayer specific tailored advertising messages. These messages could besimple text or complex animations.

Heart Beat Monitoring

A heart beat monitor operates within the machine 80 that is able to becoupled to the PSGS 70 system. This monitoring system gives the PSGS 70the knowledge that the EGM is alive and has not been compromised by anyproblems.

In practice, the heart beat is a message format that is sent to ensurethat all the components of the machine 80 are still active. If thecomponents of the machine 80 are not up and active enough, the PSGS 70will disconnect the machine 80 from the system or will send commands toshut down the machine. In this way, no player would continue to play ona machine that is not connected to the PSGS system 70.

Such a message could be sent at any time period, such as, for example,every thirty seconds. Many components could be polled, for examplemessages could be sent to the game, the card reader monitor 24, and/orthe server 70. If any one of those components drop out, the heart beatmonitoring system can disable PSGS functionality.

The heart beat monitor can be a process running on the game 80processor, which communicates with other software processes or hardwareprocesses within the game, within the PSGS server 70, or elsewhere onthe architecture 10.

The following points can be considered. This process is defined as themonitoring of critical system components on a fixed interval basis. Ifthat heartbeat is lost, predefined steps can be taken to either continueoperations in a secure mode or perform an orderly shutdown of thesystem. In the case of the PSGS 70 system, the primary purpose is toinsure the robustness and reliability of the overall gaming system. Itis critical that the player be assured that contributions derived fromcoin-in are attributed to their session/account in a timely and accuratefashion.

Generally, this monitoring occurs between certain critical systemcomponents. In the case of a dual server solution, a heartbeat ismaintained between the two servers such that the “standby” server canassume responsibility if the heartbeat is lost with the “live” server.In the case of the PSGS 70, this monitoring occurs between these majorinternal and external system components: game (internal to machine 80),message controller 84 (internal to machine 80) Card Reader Monitor 24(internal to machine 80), PSGS server 70 (external to machine 80).

As defined in the configuration options, a heartbeat message is sentbetween all major components every n seconds. The component, uponreceipt of the heartbeat message, must respond within n seconds with anacknowledgement (Ack) message. If a response is not received, thesending component is responsible for notifying the local controllingauthority that communication has been lost and PSGS functionality shouldbe disabled.

An example basic logic flow of a sample heartbeat between 2 componentsis illustrated in FIG. 12, and an example message flow diagram isillustrated in FIG. 13.

Representative examples of a message flow is as follows:

Successful Message Controller to Card Reader Monitor transaction:

1) Message Controller 84 sends heartbeat to Card Reader Monitor 24

2) Message received by Card reader monitor 24 and acknowledgementmessage sent back to Message controller 84.

3) Message received by MC and no action taken.

Unsuccessful Message Controller to Card Reader Monitor transaction:

1) Message Controller (MC) sends heartbeat to Card Reader Monitor (CRM)

2) Message either received by CRM and acknowledgement message sent backto MC and not received or message never received by CRM

3) MC takes appropriate action by sending message to Game disabling PSGSfunctionality.

4) Game initiates PSGS disable

5) Simulates card-out

6) Notifies player of loss of communication

7) Sends session data to server and closes out session

Upcoming Event Indicator

Different bonuses provide incentive for someone at a gaming machine toplay additional games. In embodiments of the invention, an indicator maybe presented on the gamescreen 82 when a bonus or other type of eventmay occur in the near future. Thus, when the player sees the indicator,they may be enticed to stay at the game longer and wait for the event tooccur.

A lucky coin bonus is a bonus in which an award is won by a player aftera randomly selected amount of total play has occurred on participatingmachines. Such bonuses are well known in the industry and appear in, forexample, U.S. Pat. No. 6,375,569.

A lucky coin indicator is a type of upcoming event indicator, which, asdescribed above, is a visual indicator of the lucky coin bonus that ispresented to a player when the player is playing a gaming device.

In one embodiment, the indicator appears on the gaming screen on one ofthree conditions. In the example illustrated in FIGS. 14-16, theindicator is presented as a bird that flies across the gaming screen, orperforms other actions.

For example, as illustrated in FIG. 14, a lucky coin identifiercommunicates to a player that a bonus may be awarded at any moment. Inthe case that the indicator is based on information stored somewhere onthe architecture 10, the game 80 can make the decision to trigger theanimation based upon the stored data. For instance, the bird may movewhen the card is inserted into the gaming device 80. This one method forsuch a PSGS 70 system, but is not the only method available.

As illustrated in FIG. 15, the bird can move based upon any number offactors, such as: coin-in, games played, time, random times, specificgame outcomes, sets of game outcomes, consecutive game outcomes, Xoutcomes in Y tries, outcome sets/unit time, outcomes relative toothers, number of points earned, gross win/loss, win/loss per unit time,visit frequency, handle per trip, handle per unit time, continuous play,at a lucky time, and with an electronic drawing. In FIG. 15, the bird isflying by but not initiating a bonus. In this picture the bird is simplyreminding the player that they qualify for a lucky coin bonus. In such asystem, the player may be enticed to play additional games or play atthe gaming machine 80 for a longer time if they believe a bonus or otheradvantage will be awarded shortly.

As illustrated in FIG. 16, the bird dropping something, such as detoursigns, indicates the initiation of the bonus. By dropping the detoursigns as if they were symbols, the game feels familiar to the customer.The advantage of this process is that a customer no longer has to beconfused about why they won a mystery or lucky coin award. The vulturereminds them of the award and creates a perceived rhythm to the awardingof the lucky coin award.

The indicator could be used to signal impending or immediate awarding ofother awards. For example, it could trigger a redemption box to redeemcollected souvenirs.

Game Verification

Because the game 80 may not be directly connected to the PSGS 70 system,game verification is a unique way of ensuring that the proper game isconnected to the PSGS network 10. This verification can be performed bya secure Java classloader and an in-memory verification.

In embodiments of the invention using a Java Classloader, each class isloaded up into the JVM goes through a check first, and a signature, iscomputed. The signatures are then checked against known good signaturesthat have been pre-computed and stored in a non-volatile memory. In someembodiments, a hash mark check sum value of a signature is performed oneach class. In this process, as the machine is powered up, a processruns that computes a signature on a CD that is present in the game. Thesignature is compared to a pre-calculated signature stored innon-volatile memory, for example an EEPROM. If it matches, the gameproceeds to the next stage of the verification. If the signatures do notmatch, the game is prevented from connecting to the PSGS 70 network.

In embodiments of the invention using in-memory verification, a list ofstandard processes that are authorized to be running on the machine aresampled every so often, for example every few seconds, and a query ismade to the proc-file system, which is built up a list of processes. Theauthorized list is compared to the proc-file system. If the lists match,then the machine is authorized. If they do not match, the machine isshut down, or disconnected from the PSGS network 70.

In one embodiment, the entire list of processes is memorized, then eachprocess is independently verified. In some embodiments, the uniquesignature is derived based on the file name, the path, the command lineparameters and other pertinent information.

Additional details of both the memory verification and the Javaclassloader are illustrated below.

A basic requirement levied by gaming regulators is for the continualverification of memory utilized by a gaming machine 80. The basicpremise behind this is that the known “memory map” is constantly beingcompared at a byte level to a known good and that if the maps differ,the game will fault.

Since the gaming machine 80 can utilize a dynamically loading operatingsystem, it is virtually impossible to predict what will be loaded where(and at what time). As such, an alternative method can be used.

Implementation

Implementation of verification utilizing a /proc file system is a twostep process. The first step is accomplished at build time and thesecond step is accomplished at runtime.

At build time, a list of authorized processes is derived from a testconfiguration of the game. This is combined with the known operatingsystem processes that are authorized to be running on the game machine80. Once the combined list has been created, it is run through a seriesof custom applications used to extract information about those processes(process name, invocation path, command line parameters, memoryutilization, etc.). This information is then used to create a uniquesignature for each process. Once the series of unique signatures hasbeen created it is stored on EPROM for future utilization.

At run time the /proc system is continually accessed to derive a list ofprocesses that are active at that moment in time. Since not allprocesses are guaranteed to be active at all times, a direct one for onecomparison cannot be made. Instead, a signature for those processes thatare currently active is derived using the same techniques as used atbuild time. After the signature has been derived, the correspondingsignature is extracted from the EPROM and is compared. If the signaturematches, the game continues on. If it does not match, an entry is madeto the system log and the game faults. If, during the process ofextracting a signature from the EPROM, one cannot be found for theprocess currently in memory, the game will fault.

Java Classloader

The purpose of System Verification is to continuously check that thegaming device is in a known state—a known state being that known andonly known processes are running and that known and only known Javaclasses are being executed.

During game execution three pieces come together for the successfulverification needed to allow the game to continue to execute: the CDthat the game code and data are delivered on, the security prom whichmust be matched with the CD, and the run time environment of theexecuting game.

The CD contains all executables and data needed for game execution. Thechanges to CD from previous version of this platform to support systemverification is the additional code to track and verify classes andprocesses loaded into the run time environment. The CD is stored withina game cabinet, outside the reach of patrons.

The security prom contains checksums and signatures to verify thevalidity of the CD. The security prom could contain an MD5 checksum ofthe entire CD to ensure a valid CD was loaded. This data remains inplace and still actively verifies that the CD and security prom loadedon this machine are indeed a matched set. The security prom can alsoinclude the class and process signatures required to support systemverification. A seed used to create these signatures is determinedduring the build process and is unique to each revision of CD/prom pair.

The run time environment has 2 additions to support Systemverification; 1) code to track which classes and processes are currentlyloaded into the runtime environment and 2) code to generate signaturesfor these loaded classes and processes and compare the active signatureswith the known signatures located on the security prom. If the signatureof any active class or process does not match that on or is not found onthe security chip error messages are logged and the game is terminated.

Prom Setup

The signature data for verification is added to the ‘security’ chip onthe prom board. There are now four(4) sections to the prom image: md5checksum, md5 executable, class signatures, and process signatures. Eachsection has 4 bytes of size (size of data only) followed by the actualdata.

Md5 Checksum:

This file format remains unchanged from previous versions. This imagecontains one line per file where each line contains a md5 check sum andthe file name and one additional line to define the game/percentage thismachine can run.

There is a special provision on the md5 checksum where if the size isequal to “!agp” then there is no md5 checksum data and the system isdeemed to be a development machine (md5 checksum verification isdisabled).

Md5 Executable

This image starts with a few lines to define the game/percentage thismachine can run. The rest of the file contains one line per file whereeach line contains a md5 check sum and the file name.

Class Signatures

This section is in the security prom to support System Verification.This section contains the name and a signature for each class that isallowed to be loaded while the game is executing.

Process Signatures

This section in the security prom supports System Verification. Thissection contains the name and a signature for each process that isallowed to be running while the game is executing.

Startup

Given the security of the JVM there is no way to extract the activeclasses out of the JVM itself short of opening up gaping security holesand adding the performance hit of enabling the debugging mode of theJVM. To keep track of which classes are currently active we add our ownclass loader to both load and track active classes. We tell the JVM toadd our class loader into the class loader structure with the—

Djava.system.class.loader=classloader. VerifyClassLoader argument on theJVM startup command.

Our class loader was created by starting with the most secure of theavailable Java class loaders, adding more restrictions to the sourcesfrom which classes can be loaded from, and adding the ability toremember each and every class that is loaded into the JVM. At startup weexplicitly specify to the JVM the location and name of our custom classloader.

The JVM class loading is done in a parent-child relationship with thedefault loader the parent and added class loaders the children. Thedefault class loader is always present and our class loader becomes theonly child class loader. When the JVM is asked to load a new class itcalls the parent class loader which looks for all classes available in‘CLASSPATH’; if the class is not found it then delegates the loading ofthe class to the child class loader. In order to effectively disable theparent class loader we modify the startup to set ‘CLASSPATH’ so that itdoes not point at any classes forcing the default parent class loader toalways delegate to our class loader.

Finally we add the argument ‘-Djava.system.class.loader.path=/cdrom’(/space/target for development systems) to the startup which tells ourclass loader where to look for known classes. No special startup code isneeded for process verification.

Run Time Checking

Runtime verification is accomplished by creating a verification threadwithin the ATM. The thread performs verification on demand or 60 secondslater than the last verification. Currently on demand verification isdone on a door closed event or a jackpot cleared event.

The verification thread creation and on demand kicks are done in theBaseGame object. The verification thread calls back to the destroymethod of BaseGame if verification fails and the verification is nottagged as being in development mode. The verification thread handlestiming and the interface between the game and the verifier code. Theactual verification of active classes happens in the classloader andprocess packages. The basic verification is to read the class signaturesoff the security chip and compare these expected signatures to those ofthe currently active classes which are tracked within our custom classloader. If a signature mismatches or an active class does not have asignature in the ‘security’ chip the verification fails and the game isshut down (it only babbles in developer mode).

The actual verification of active processes happens in the processpackages. The basic verification is to read the process signatures offthe security chip and compare these expected signatures to those of thecurrently active processes which can be gathered from the Linux kernel.If a signature mismatches or an active process does not have a signaturein the ‘security’ chip the verification fails and the game is shut down(it only babbles in developer mode).

System Terminal Support for System Monitoring

Casino and player satisfaction often hinge on very similar requirements;robustness of game play and reliability of the gaming platform. In thepast, if there was a fault and/or discrepancy in the gaming platform'sperformance, it was often difficult if not impossible to narrow down andrapidly find the cause without extensive (and often on-site) efforts ofdevelopment staff.

The need exists to rapidly detect, diagnosis, and “treat” the symptomsof an Electronic Gaming Device (EGM). To accomplish this: a remotemonitoring capability is installed on the gaming machine 80; and remoteaccess is attained, preferably in a secure and reliable manner.

Remote access uses networking support, which necessarily opens as apossibility for intrusion. As such, a secure system is incorporated toauthenticate the requestor as a valid user who is authorized to performactions on this device. SSH is an industry standard protocol suited forjust such a task.

Using SSh allows a connection to be made into a gaming device from aremote location, and allows monitoring activity to occur on that gamingdevice. OpenSSH is a suite of tools to help secure network connections.A list of features includes: strong authentication. Closes severalsecurity holes (e.g., IP, routing, and DNS spoofing), Improvedprivacy—all communications are automatically and transparentlyencrypted, secure X11 sessions—the program automatically sets DISPLAY onthe server machine, and forwards any X11 connections over the securechannel, Arbitrary TCP/IP ports can be redirected through the encryptedchannel in both directions (e.g., for e-cash transactions). Noretraining needed for normal users. Never trusts the network. Minimaltrust on the remote side of the connection. Minimal trust on domain nameservers. Pure RSA authentication never trusts anything but the privatekey.

Client RSA-authenticates the server machine in the beginning of everyconnection to prevent trojan horses (by routing or DNS spoofing) andman-in-the-middle attacks, and the server RSA-authenticates the clientmachine before accepting .rhosts or /etc/hosts.equiv authentication (toprevent DNS, routing, or IP-spoofing). Host authentication keydistribution can be centrally by the administration, automatically whenthe first connection is made to a machine. Any user can create anynumber of user authentication RSA keys for his/her own use. The serverprogram has its own server RSA key which can be automaticallyregenerated every hour. An authentication agent, running in the user'slaptop or local workstation, can be used to hold the user's RSAauthentication keys. The software can be installed and used (withrestricted functionality) even without root privileges. The client iscustomizable in system-wide and per-user configuration files. Optionalcompression of all data with the compression tool gzip (includingforwarded X11 and TCP/IP port data), which may otherwise result insignificant speedups on slow connections.

Complete Replacement for rlogin, rsh, and rcp.

Anyone who has access to any machine connected to a non-encryptednetwork can listen in on any communication. This is being done byhackers, curious administrators, employers, criminals, industrial spies,and governments. Some networks leak off enough electromagnetic radiationthat data may be captured even from a distance.

If, during log in, a password would go to the network in plain text, anylistener could use your account to do any evil he likes. Many incidentshave been encountered worldwide where crackers have started programs onworkstations without the owner's knowledge just to listen to the networkand collect passwords. Programs for doing this are available on theInternet, or can be built by a competent programmer in a few hours.

Many companies are not aware that information can so easily be recoveredfrom the network. They trust that their data is safe since nobody issupposed to know that there is sensitive information in the network, orbecause so much other data is transferred in the network. This is not asafe policy.

Utilizing OpenSSH as a foundation for remote access and monitoring ofthe EGM provides a baseline which mitigates this risk.

Access

At startup, each gaming machine 80 as part of the init (boot) processstarts an SSH server. This server continually runs in the background asa server process listening for and responding to requests for accessfrom external sources.

A client application (external to the gaming machine 80) will attempt toconnect to the gaming machine 80 via ssh. The following general stepsare followed to gain access:

-   The application (most often a request for a simple login terminal)    is authenticated via a comparison of the public/private keys. Access    is granted if: the keys are found to be authentic, and the    requesting individual has an account on the EGM, the requesting    individual provides the proper password, and the resource requested    exists on the EGM.

Local Monitoring

-   Once authenticated access to the gaming machine 80 has been gained,    a variety of applications can be accessed to perform forensic    diagnosis on the machine. The user could:-   View game specific logs-   View system specific logs-   View currently running system and user processes-   View system resource (memory) utilization

Remote Monitoring

-   Remote monitoring can also be accomplished by the installation of    applications on the gaming machine 80 which receive requests for and    transmit status information to external monitoring systems.    Representative examples could be:-   Game Status-   Overall System Status (processes, memory utilization, etc)-   Example Peripheral status:-   Printer (online, paper low, etc)-   Hopper status (hopper online, hopper full, etc)-   Bill Stacker (stacker full)-   Touchscreen active-   Sound system active

All requests would go through the same ssh authentication process asdescribed above since (in this case) ssh would be used as a tunnelingprotocol to allow internal process A and external process B tocommunication of a secure and encrypted pipeline.

In some embodiments, a special chip can be installed in a gaming devicethat can allow remote access to a gaming machine only if the specialchip is present. For example, the special chip or code can indicate thatthe game is in a “developer” mode, and only allows secure access intothe gaming device if the developer chip is present in the gamingmachine.

1-11. (canceled)
 12. A gaming system, comprising: a plurality of gamingdevices coupled to a gaming network, the gaming devices having a paytable; a player tracking system configured to identify a player; and acentral host system structured to communicate with the gaming devicesand structured to store historical information about a player of agaming device, the central host system including a notification systemfor a table for a card game wherein the notification system isconfigured to: (a) identify whether a player position at the table isvacant; and (b) if a player position is vacant: (i) retrieve a wait listof potential players, (ii) determine if a potential player on the waitlist has been identified at one of the gaming devices, and (iii) if thepotential player on the wait list has been identified at one of thegaming devices, notify the potential player of the existence of thevacancy and of his or her status on the wait list.
 13. The gaming systemof claim 12, wherein the vacancy notification causes a message to bedisplayed on a display device of a gaming device.
 14. The gaming systemof claim 12, wherein the gaming devices include at least one playeridentification input device which enables a player to be identified at agaming device.
 15. The gaming system of claim 12, wherein the playertracking system includes a card reader.
 16. The gaming network of claim15 further including a processor-implemented card reader monitorelectrically connected to the card reader, the card reader monitor beingconfigured to verify the card in and out operation of the playertracking system.
 17. The gaming system of claim 12 wherein the centralhost system is structured to change a pay table of the gaming device atdifferent times of the day, at certain time intervals, or for differentpromotions.
 18. The gaming system of claim 12 wherein the central hostsystem is structured to change a pay table of the gaming device inresponse to identifying or receiving information about a player.
 19. Thegaming system of claim 12 wherein the central host system is structuredto change a pay table of the gaming device based on a physical locationof the gaming device.
 20. A method of operating a gaming system,comprising: (a) identifying whether any of a plurality of a playerpositions at a table for a card game is vacant; and (b) if at least oneof the plurality of player positions at the table is vacant: (i)retrieving a waiting list of potential players, (ii) determining if apotential player on the waiting list has been identified at one of aplurality of gaming devices, and (iii) if the first potential player onthe waiting list has been identified at one of the gaming devices,notifying the potential player of the existence of the vacancy and ofhis or her status on the waiting list.
 21. The method of claim 20,wherein the vacancy notification causes a message to be displayed on adisplay device of a gaming device.
 22. The method of claim 20, whichincludes enabling a player to be identified at one of the plurality ofgaming devices.